home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Aminet 2
/
Aminet AMIGA CDROM (1994)(Walnut Creek)[Feb 1994][W.O. 44790-1].iso
/
Aminet
/
gfx
/
show
/
AGMSFilm2.lha
/
AGMSMakeFilm.doc
< prev
next >
Wrap
Text File
|
1993-01-05
|
6KB
|
140 lines
AGMSMakeFilm combines picture and sound data files into a cartoon data file
that can be shown with AGMSPlayFilm. See AGMSFilm.doc for details about
file format and other things.
Here are the command line options:
From/...
The list of input files. You can use ARP wildcards, the files from each
wildcard will be used in alphabetical order. For example, "from *.snd
happy*.pic old.film" will result in all .snd files in alphabetical order
followed by the selected .pic files in alphabetical order followed by the
old.film file. The "from" keyword seems to be required to avoid confusing
the command line parser.
What kind of input files do you need? IFF pictures and sounds, with at
least one picture and one sound. The film will use all the pictures and as
much sound as fits. The sounds can be in mono or stereo, mono ones will
appear in both left and right channels in the film's stereo sound track.
The
sound files must be in uncompressed format
(most currently are). Note
that the output of AGMSMakeFilm is also an IFF file containing pictures and
sound. You can use an old film as an input file, possibly listing new sound
files before the old film so that they come before the old sound track.
Also, the pictures should have the same palette (the palette and screen
modes / size of the first picture will be used to display all of them).
This is useful for cropping existing images - just specify a smaller picture
for the first one in the film and the remaining ones will be cropped to fit
it. Unlike ANIM5 cartoons, you should not repeat the first two frames at
the end. Put in all the frames of the cartoon in the order you want them,
just like a real piece of film.
One last glitch: things can get very slow when dealing with multi-megabyte
IFF files. This seems to be a problem with AmigaDOS file writing
operations. If you notice that AGMSMakeFilm is getting ridiculously slow,
use the "Addbuffers dh0: 1000" command. That will consume about 550K of
memory and give you better performance. Repeat if needed.
To/A
This is the required file name for the output file. The file can be very
large, so make sure your file system has enough space.
SecondsPerFrame=Secs/K
The default for this optional parameter is 0.1 seconds per frame. To
specify a value, you need to type something like "secs 0.25" on the command
line. Every picture you specify in the input will be displayed for this
many seconds when the film is shown. This is of course 1 divided by the
number of frames per second; 15 frames per second corresponds to a "secs"
value of 0.066667. It doesn't have to be a multiple or factor of the video
display rate and is independant of PAL and NTSC modes (the audio hardware
controls the overall timing of the film).
ImageFileBuffer=IB/K
Size of the buffer that will be used to speed up reading your IFF image
files. The default is 65536 bytes. If you want extra performance, make it
as large as your largest input picture. If you are short of memory, you can
make it smaller.
AudioFileBuffer=AB/K
The size of the buffer that will be used to speed up reading your IFF audio
files. If your sound files are stereo, two buffers of this size will be
used. The default size is 32768. A good size is enough for one second of
sound.
FilmFileBuffer=FB/K
The size of the buffer for the film output file. Make this one as large as
possible, the default is 1048576 bytes. Every time it fills up, one
AmigaDOS Write function call is done.
One of the limitations of the Amiga's FastFileSystem (2.04) is that it is
slow when writing at the end of a multimegabyte file. It seems to have to
examine all the disk sectors that keep an index of the data sectors when it
does a Write at the end of the file. Nope, no seeking involved, just a
simple Write. With megabytes of data, there are quite a few index sectors
(hundreds if not thousands) so that Write can generate quite a bit of disk
activity beyond that needed for the writing of the actual data.
Fortunately, the AmigaDOS AddBuffers command can be used to cache those
index sectors in memory. So, try something like "AddBuffers DH0: 1000" if
performance is slow.
Between the large buffer size and the AddBuffers, you should be able to get
good performance, at the expense of megabytes of memory. You do have one of
those 64 megabyte RAM boards? :-)
Verbose/S,MegaVerbose/S,UltraMegaVerbose/S
Various verbosity control switches. The default is no verbosity. Other
settings are useful if you want to see the internal structure of IFF files,
particularly UltraMegaVerbose which will describe palette values and display
modes for pictures and audio parameters for sounds in your input files. I
recommend the "Verbose" setting.
QuickScan=QS/S
Use this option if you want the first scan of files to stop as soon as the
first audio and video data are encountered. The advantage is speed. The
disadvantage is that any sounds after the last sound scanned are ignored.
In other words, use this option only if you put all your sound files before
your picture files or if you only have one sound file. Don't use it if you
are using an old film file as an input - it will stop scanning at the first
frame in the old film, so your sound track will only include the sound from
the first frame and not the rest of the old film.
Control-C
Type a control-C or use the CLI command "Break" to abort the program.
Distribution
AGMSMakeFilm is FreeWare. Copyright (c) 1993 by Alexander G. M. Smith.
That means that you can use it freely, can't blame me for anything that goes
wrong (there are definitely a few bugs left), and you shouldn't expect more
from it than you paid for it. Also, don't blame me if your computer runs
out of memory when you use the buffer settings I recommend :-).
Bugs
Let me know if you find any. My E-mail addresses are in the program credits
(use "?" as the command line argument and then a second "?" at the prompt to
see the credits). I've found a sporadic memory trashing bug, but it seems
to have gone into hiding after I'd rewritten the disk buffering. It shows
up as the program trying to open a file with no name.